1. Field of the Invention
The present invention relates generally to embedded computing systems, and more particularly to updating a non-volatile memory in an embedded system.
2. Description of Related Art
Embedded computing systems often have limited processing and storage resources, and are basically dedicated for running a single program application, which is usually error-free and calculable for all relevant use situations during operation. For example, methods have been developed for updating a flash memory of a computer system that reserve such update hardware in the form of a certain additional memory area in an additional “locked” memory space in order to provide such security against update failures.
A disadvantage of such embedded computing systems is that the updating process requires a service provider to connect separately to each embedded system. For example a 1:1 relationship between a service provider and an embedded system is generally required. This results in a tax on resources, and as the number of systems to be updated increases, resources are taxed for longer periods.
Generally, as both computing resources and storage resources are restricted in size and performance in embedded systems, a flash memory in an embedded system controller provides efficiencies by providing a persistent media for storing purposes (applications, user data, application environment), and by serving as an execution media. The term “Flash” memory in the present invention means any non-volatile memory used to store either data and/or programs. Thus, it may also include a battery-buffered volatile memory, and other forms of non-volatile RAM. For example, when the system is booted, the processor will start to execute the bootstrap code out of the flash memory. Afterwards an operating system is loaded from said flash memory into the RAM, for example, a dynamic random access memory (DRAM) device, and is executed. Applications often do not need to be loaded completely into DRAM devices because the operating system (OS) provides mechanisms of on-demand loading of code pages. As a result, some DRAM space is saved because it is unnecessary to copy all the application code from flash memory into DRAM.
This dual use, however, creates problems when the flash memory should be updated. While a program is executed, it will generate page faults, which cause the OS to load the missing code out of the flash memory into the DRAM. This makes it impossible to update the application memory area of the flash memory with a newer version of the program. In order to do so, the program must be stopped and unloaded. Then the flash memory, which was used by the program, can be updated. But this approach is not possible for those memory areas which are permanently in use for critical programs, for example, an initial application like “init” in UNIX™ or Linux™ systems and the associated shared libraries like “glibc”. In these cases it is impossible to stop and unload the applications and libraries to make the used flash space available for updating. Since these programs are usually loaded at boot time, it can only be unloaded at boot time with a new boot. However, at boot time it is usually not possible to select where these programs should be placed. Therefore, it is not possible to update these flash memory areas in-band, i.e., by the aid of a functional path under use of the own embedded system processor.
There are three solutions for this situation. Prior art provision of an external hardware path into the system can be used, which allows the flash memory to update without the need to boot the system or to run programs. Alternatively, additional redundant flash memory, i.e., a second flash memory bank, which holds a backup copy of the programs can be used. In case of a code update, this version is written first, and then the system is rebooted with the indicator to fetch the programs from the 2nd flash bank. When this bank is booted, the flash space of the 1st bank can be overwritten. Another solution includes usage of additional DRAM to store the critical applications, making an update of the flash memory possible at any time.
All three solutions are expensive, because they require either additional hardware circuitry, duplicate the amount of necessary flash memory or increase the needed DRAM space significantly. In particular, for embedded systems, which are required to remain on low-price level, such additional costs can hardly be tolerated. It can be seen then that there is a need for a method, apparatus and program storage device for updating a non-volatile memory in an embedded system.